The Internet is commonly used as a medium over which remote parties can conduct information transactions. For example, using a browser application on a computer, a shopper can select items to be purchased from a remote vendor. The shopper may virtually place the selected items into a virtual shopping cart. Each time that the shopper places an item into the virtual shopping cart, the shopper's browser may send, to the vendor's server, a request that indicates which item the shopper has selected. For each such request, the vendor's server may send, to the shopper's browser, a response that indicates that the selected item has been placed into the virtual shopping cart. The requests and responses may be structured, for example, according to the well-known Hypertext Transfer Protocol (HTTP).
Multiple shoppers might send requests to the same vendor. In order to keep the contents of the shoppers' virtual shopping carts separate, each shopper may be assigned to a separate “session.” Each such session is associated with a different session identifier that is generated when the session is initiated. Requests indicate the session identifier of the session to which those requests pertain. For example, requests from a first shopper might indicate a session identifier of “1,” while requests from a second shopper might indicate a session identifier of “2.” Using the session identifiers, the vendor's server can internally maintain separate session state information for each separate shopper, thus keeping the second shopper from placing items into the first shopper's virtual shopping cart, and vice-versa.
In order to handle many requests concurrently, a particular vendor might have multiple servers that can receive requests. For example, all of the requests to a particular vendor might be received initially by the vendor's “load balancer,” which distributes the requests among the vendor's servers. The load balancer might distribute the requests, for example, according to a random or “round robin” scheme.
Although session state information for multiple sessions can be stored in a central repository that each of the servers can access, it is not efficient for a server to access the central repository every time that the server needs to read session state information. To improve efficiency, each server may locally maintain separate session state information for sessions that have been assigned to that server. When a server receives a request that pertains to a pre-existing session for which the server has no local session state information, the server sends the request to a different server. According to one hypothetical approach, each request might indicate a “primary server” to which the request should be sent. All of a particular session's requests might indicate the same primary server.
Occasionally, a server may fail. When a server fails, the requests that normally would have been sent to the failed server need to be sent to one or more of the servers that remain operational. The servers to which such requests are to be sent are called “backup servers.” When a particular session's primary server fails, all requests pertaining to the particular session should be sent to the same backup server so that the integrity of the particular session's state information is maintained.
Theoretically, if a server that receives a request (the “recipient server”) detects that the request's primary server is not currently operational, the recipient server might query each of the other operational servers in order to determine if any of the other operational servers has assumed the role of backup server for the session to which the request pertains. If the recipient server determines that one of the other operational servers has assumed the role of backup server for the session to which the request pertains, then the recipient server might send the request to the backup server. Alternatively, if the recipient server determines that none of the other operational servers has assumed the role of backup server for the session to which the request pertains, then the recipient server might assume the role of backup server. In this manner, it could be assured that no more than one operational server has assumed the role of backup server for the same session.
The above approach might be feasible if very few servers are available to assume the role of backup server for a particular session. However, if there are many servers, the time and bandwidth consumed by the many queries required by the above approach would be prohibitive.